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1  Executive  Summary 


The  AFLC/Arri  Standards  Project  is  testing  the  Military  Standard  for 
the  Automated  Interchange  of  Technical  Information,  MIL-STD-1840  (the 
Standard).  The  objective  of  the  tests  is  to  demonstrate  the  validity  of  the 
transfer  protocol  defined  in  the  Standard  itself  and  the  viability  of  stan¬ 
dardized  formats  for  the  transfer  of  technical  information  defined  in  other 
specifications  used  by  the  Standard. 

One  document  (file  set)  was  prepared  by  Boeing  Military  Airplane 
Company  (BMAC)  for  this  test.  The  document  was  prepared  in  accor¬ 
dance  with  Appendix  A  of  the  December  12, 1986,  draft  revision  of  the 
Standard.  The  file  set,  on  magnetic  tape,  was  delivered  to  the  ATOS 
laboratory  facility  at  SYSCON  Corporation,  San  Diego,  California,  for 
testing.  The  file  set  consisted  of  a  declaration  file,  SGML  tagged  text 
files,  and  IGES  illustration  files  written  on  magnetic  tape  in  accordance 
with  FIPS  PUB  79  and  the  Standard. 

The  tape  format  was  in  complete  accordance  with  FIPS  PUB  79.  This 
critical  point  in  the  transfer  process  was  successful.  Almost  any  failure 
here  would  mean  complete  failure  of  the  transmission.  The  declaration 
file  was  also  completely  acceptable. 

The  text  files  were  generally  successful  in  meeting  the  requirements  of 
the  USAF  SGML  tagging  scheme.  The  quality  could  be  characterized  as 
very  good  for  a  first  effort  but  not  quite  good  enough  for  a  production 
environment.  After  a  few  minor  corrections,  a  reasonable  reproduction  of 
the  original  could  be  generated.  Inexperience  and  lack  of  automated 
quality  control  (AQC)  tools  account  for  the  errors. 

The  illustrations  transmitted  in  IGES  format  matched  the  original 
published  illustrations  very  well  except  for  the  type  fonts  in  the  text 
callouts.  Font  problems  with  IGES  have  been  noted  since  the  beginning 
of  the  test  program.  In  general,  this  part  of  the  test  was  a  success  with  the 
exception  noted. 

The  goal  of  the  test  was  met,  even  with  the  deficiencies  noted.  Based 
on  the  results  of  this  test  and  prior  observation,  it  is  recommended  that: 

1.  Sending  systems  be  provided  with  AQC  tools  and  improved  reference 
documentation  to  assist  preparers  of  SGML  text  files. 

2.  IGES  be  improved  with  respect  to  text  fonts,  including  alphabet  size 
and  set  width  specifications  and  style  and  emphasis  parameters. 
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Boeing  Military  Airplane 
Company  Transfer  Tests- 
Summary  of  Compliance 
toMIL-STD-1840(12 
December  1986) 


Major  Compliance 


File  Set 


Categories 

1 

Transmission  Envelope 

ANSI  Level  3  tape 

pass 

MIL-STD-1840  tape 

pass 

Declaration  file 

pass 

Header  records 

part 

SGML 

Correct  use 

part 

No  minor  errors 

fail 

No  tag  typo's 

pass 

IGES 

Version  3.0 

fail 

ParserA^erify 

part 

Subset  compliance 

pass 

All  good  images 

pass 

Comments 


Accidental  compliance 


ccrrr 

All  good  images 


pass  =  compliant  in  all  respects 
part  =  partial  compliance,  usable  data 
fail  =  noncompliant,  unusable  data 
-  =  no  graphic  data  in  this  form 
*  =  ureadable  tape 
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-  Major 'iCompIiance'g^^^^^ 

Categories  Explanation  of  Category 


Explanation  of  Table  of 
Summary  of  Compliance  to 
MIL-STD-1840  (12  December 
1986). 


Transmission  Envelope 
ANSI  Level  3  tape 
MIL-STD-1840  tape 

Declaration  file 

Header  records 


The  “wrapper”  around  the  documents 
The  tape  complies  with  FIPS  PUB  79 
The  tape  complies  with  specific 
MIL-STD-1840  req'ments 
The  Document  Declaration  files 
are  correct 

The  Header  records  for  each  data  file 
are  correct 


SGML  SGML  tagged  text  files 

Correct  use  The  source  system  personnel  under¬ 

stand  SGML  broadly 

Required  tags  present  All  required  tags  are  present 
Tags  keyed  correctly  All  tags  are  keyed  correctly 


IGES 

V3.0 

Parser A'^erify 
Subset  compliance 
All  good  images 


Illustrations  in  IGES  format 

The  files  are  in  conformance  with 
Version  3.0 

The  file  passes  the  parser/verifier 
without  serious  error 
The  files  comply  with  MIL-STD-1840 
IGES  subset  req'ments 
The  IGES  postprocessor  produced  an 
accurate  image 


CCITT 

All  good  images 


Illustrations  in  CCITT  Raster  format 

Usable  images  can  be  derived  from 
the  data 


pass  =  compliant  in  all  respects 
part  =  partial  compliance,  usable  data 
fail  =  noncompliant,  unusable  data 
-  =  no  graphic  data  in  this  form 
*  =  unreadable  tape 
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2  File  Set  Preparation  and  Processing 


The  transmission  tape  was  written  at  BMAC,  Wichita,  on  a  VAX.  The 
IGES  illustrations  were  generated  on  an  Auto-trol  system  and  transferred 
by  tape  to  the  VAX. 

One  document  was  prepared  by  BMAC  for  this  test.  The  document 
was  the  Am  Reference  T.O.  86-1.  The  document  was  prepared  in 
accordance  with  Appendix  A  of  the  December  12, 1986,  version  of  the 
Standard. 

The  file  set,  on  magnetic  tape,  was  delivered  to  the  ATOS  laboratory 
facility  at  SYSCON  Corporation,  San  Diego,  California,  for  testing.  The 
initial  tape  processing  and  the  majority  of  the  testing  was  performed  on  a 
VAX.  An  Auto-trol  AGW  70  was  used  to  convert  the  IGES  files  to  a 
CAD  format  and  subsequently  to  a  plotter  format.  The  plotter  files  were 
then  converted  to  a  form  acceptable  to  the  QMS  laser  printer.  Text 
hardcopy  was  output  on  the  same  printer. 

Appended  to  the  body  of  the  report  are  paired  exhibits  of  pages  from 
both  documents  in  their  as-published  form  and  in  the  as-transmitted  and 
processed  form. 

The  file  set  was  processed  in  the  ATOS  laboratory  with  a  combination 
of  specially  built  and  commercially  available  software.  The  file  set  con¬ 
sisted  of  a  declaration  file,  SGML  tagged  text  files,  and  IGES  illustration 
files  written  on  magnetic  tape  in  accordance  with  FIPS  PUB  79  and  the 
protocol  specified  in  the  Standard. 
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Test  Results 


The  test  results  for  the  transmission  envelope  are  presented  first. 
Following  that,  the  results  for  the  document  are  presented  for  the  SGML 
text  files  and  the  IGES  illustration  files. 

Problem  Numbering 

In  order  to  avoid  repetitious  statement  of  recurring  problems 
encountered  during  the  preceding  year  of  testing,  certain  problems  will  be 
identified  by  numbering  them  according  to  the  standard  involved  and  the 
order  of  occurrence:  for  example,  IGES-1  or  SGML-3.  When  the  same 
problem  is  encountered  in  a  submission  from  a  different  sending  system,  it 
will  be  referred  to  by  that  number.  These  numbered  problems  will  include 
only  difficulties  or  deficiencies  inherent  in  the  Standard  or  the  specifica¬ 
tions  on  which  the  Standard  calls.  Problems  attributable  to  preparation  by 
the  sending  system  or  by  vendor-supplied  hardware/software  will  be 
identified  separately  and  specifically. 

Transmission  Envelope 

Analysis 

The  document  transmission  envelope  consists  of  the  tape  and  file  labels 
(found  “in”  the  magnetic  tape),  the  document  declaration  files,  and  the 
header  records  for  the  text  and  illustration  files. 

The  envelope  created  by  BMAC  was  correct  in  all  respects  but  one. 

The  flaw  was  present  in  the  fourth  record  in  each  illustration  file.  The 
Standard  specifies  that  the  fourth  header  record  preceding  an  IGES  file 
shall  contain  the  value  of  the  location  attribute  found  in  the  “cfigure”  tag 
followed  by  a  colon,  which,  in  turn,  is  followed  by  the  value  of  the  ID 
attribute  of  the  same  tag  instance.  The  content  as  found  appeared  to 
contain  some  sort  of  identifier  assigned  with  sequentially  increasing 
values  for  each  illustration.  The  lack  of  the  colon  as  punctuation  pre¬ 
vented  parsing  the  record  into  two  values  which  could  be  compared  with 
the  attribute  values  of  the  “<figure”  tags.  The  flaw  should  be  classed  as 
minor  to  medium  in  severity.  The  flaw  did  not  prevent  reading  the  files 
from  the  tape  and  testing  the  files  to  completion. 
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Statistics 

The  transmission  contained  one  document.  The  document  contained 
two  text  files  and  seven  IGES  files.  Table  1  below  summarizes  the  statis¬ 
tics  on  file  sizes. 


Table  1. 

FOe  Size  Statistics 
( in  bytes) 


Am.Ref-1986.1 


Declaration  File 

231 

Text  Files 

TOOISOOOI. 

2,951 

T001S0002. 

42,309 

Total 

45,260 

IGES  Files 

FOOIQOOOI. 

106,240 

F001Q0002. 

47,520 

F001Q0003. 

188,480 

F001Q0004. 

99,840 

F001Q0005. 

88,200 

F001Q0006. 

57,360 

F001Q0007. 

77,120 

Total 

664,760 

Grand  Total 

710,251 

Text  Files 

AITI-Ref-1986-1  Analysis 

The  text  of  the  document  was  transmitted  in  two  files.  The  portions  of 
the  first  file  containing  the  list  of  effective  pages  (LEP)  and  the  Table  of 
Contents  (TOC)  were  not  composed  on  ATOS.  ATOS  automatically 
generates  these  elements  of  the  document.  The  LEP  and  TOC  files  were, 
however,  subjected  to  all  other  phases  of  the  testing. 
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The  printed  original  document  (AITI  RefT.O.  86-1)  was  produced  in 
the  ATOS  laboratory  at  SYSCON,  San  Diego,  using  SGML  tags.  In 
general  terms,  the  piupose  of  this  part  of  the  validation  test  is  to  determine 
if  a  given  application  of  SGML  can  adequately  support  the  goals  of  the 
CALS  policy  as  implemented  by  MIL-STD-1840.  In  a  more  specific 
sense,  the  piupose  of  this  test  was  to  discover  if  a  printed  document  of 
known 

tagging  characteristics  (at  the  destination  system)  could  be  closely  ap¬ 
proximated  in  appearance  and  structure  by  the  tags  used  by  the  sending 
system.  This  is  intended  as  a  test  of  the  capability  of  a  given  application 
of  SGML,  not  as  a  test  of  the  expertise  of  the  SGML  coders  at  the  sending 
system.  The  reader  is  asked  to  keep  the  distinction  in  mind  since  it  is 
inevitable  that  the  two  issues  become  intertwined  when  test  results 
are  reported. 

The  quality  of  the  tagging  by  the  sending  system  was  excellent, 
considering  that  it  was  a  first  effort.  Three  tagging  errors  were  discovered 
that  could  have  been  caught  by  a  quality  control  software  tool.  All  were 
minor,  having  to  do  with  the  “<page...>”  tag  required  by  the  Standard. 
None  of  the  errors  impeded  composition  of  the  text.  A  comment  line  was 
inserted  in  the  text  file  noting  what  repair  had  been  made.  In  the  listing  of 
the  file  “BMACl  l.txt”,  these  comment  lines  begin  with  the  string  “[co.” 
This  string,  and  any  characters  following  it  on  the  same  line,  is  accepted 
by  the  ATOS  text  composition  software  as  a  comment  and  is  not  proc¬ 
essed  into  the  final  output.  Most  of  the  comments  related  to  artifacts  of 
the  testing  environment  and  not  to  tagging  errors. 

Several  other  tagging  errors  found  would  not  have  been  caught  by  a 
QC  software  tool.  They  are  listed  below.  Not  listed  as  discrepancies  are 
the  change  version  of  the  pages  in  the  LEP  and  the  lack  of  change  bars. 
The  BMAC  text  files  were  coded  with  “change  bar”  tags.  The  ATOS  job 
setup  to  compose  the  text  treated  the  input  files  as  a  “no  change”  docu¬ 
ment,  thus  the  lack  of  change  bars,  etc. 

1.  The  distribution  notice  on  the  cover  page  differs  in  placement 
from  the  original.  The  original  used  a  <notice  type=b>  tag,  whereas 
the  BMAC  submission  used  the  simple  <notice>  tag.  Refer  to 
Exhibits  1  and  2. 

2.  Page  2-1.  Paragraph  2-2  in  the  original  was  miscoded  as  a  <pl> 
instead  of  a  <p0>,  causing  it  to  be  numbered  “d.”  in  the  BMAC 
submission.  Refer  to  Exhibits  3  and  4.  Tne  overflow  of  text  to  a 
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second  page  is  a  test  artifact  and  not  significant. 

3.  Page  3-5.  The  backslash  following  the  subparagraph  titles  is  caused 
by  a  coding  error.  The  DTD  does  not  permit  paragraph  titles  (termi¬ 
nated  with  a  backslash)  at  the  <p2>  level.  This  error  is  found  in 
several  other  places  in  the  document.  See  Exhibits  5  and  6. 

4.  Page  4-1.  The  descriptions  of  RECORD  5  and  RECORD  9  use  the 
string  “??”  rather  than  the  string  “<=”.  BMAC  coders  apparently 
could  not  determine  how  to  enter  the  “<=”  group  from  reading  the 
reference  material  supplied  to  them.  Refer  to  Exhibits  7  and  8. 

5.  Page  4-2.  The  word  “representation”  was  omitted  from  the  last  line  of 
paragraph  (4)  4.  This  caused  a  shift  of  text  allocation,  pulling  text 
from  the  next  page.  No  exhibit 

6.  Page  5-1.  The  BMAC  version  of  this  page  shows  that  “<para>”  tags 
were  omitted.  The  tags  should  have  been  placed  in  front  of  the  phrases 
“Figure  5-3...”  and  “Figure  5-4...”  Refer  to  exhibits  9  and  10. 

Some  conclusions  may  be  drawn  by  analyzing  the  detail  represented 
by  the  preceding  representative  comments. 

In  this  test  environment,  inexperience  with  the  SGML  application  may 
be  taken  as  a  “given”  and  is,  therefore,  not  significant. 

The  absence  of  simple  AQC  tools  is  significant  All  of  the  coding 
errors  detected  by  the  laboratory  preprocessing  software  and  the  text 
composition  software  at  the  destination  system  could  have  been  detected 
by  an  AQC  tool  at  the  sending  system  and,  therefore,  corrected.  The  other 
errors  noted  above  cannot  be  detected  by  simple  AQC  tools. 

These  errors  can  be  attributed  to  many  causes,  some  of  which  are: 

a.  Inadequate  reference  documentation  used  by  “taggers.” 

b.  Inadequacies  of  the  SGML  application  itself. 

c.  Idiosyncrasies  in  the  SGML  implementation  software. 

There  were  a  number  of  errors  reported  by  the  ATOS  spellchecker. 

In  the  listing  of  spelling  errors,  where  duplicates  are  deleted,  13  of  the  25 
words  listed  are  acronyms  or  names  for  programs  or  files.  These  13  words 
constituted  42  of  54  (78%)  of  the  entries  in  the  list  before  duplicates 
were  deleted. 
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Test  Results 


Two  groups  of  words  are  shown  below.  The  first  group  contains 
acronyms,  and  abbreviations  that  would  not  ordinarily  be  found  in  a 
spelling  dictionary.  The  second  group  contains  possible  English  words 
that  are  either  unknown  to  the  dictionary,  technical  neologisms,  or 
misspelled. 

ATOS,  AnaTech,  Auto-Trol,  DL,  DLEDT,  FINALPASS,  FNVAL, 

GenCode,  GenCoded,  IGEDPARS,  PLOTUPF,  RLE,  RVBIT, 

SCANTAPE,  TESTBED,  VDRIVE,  xyz 

Nongovernment,  Tech,  asks,  occassional,  ot,  phototypsetter,  plotfile, 

praticality,  validator 

Of  the  nine  words  in  the  second  group,  one  word  is  legitimate  (asks), 
two  words  are  technical  neologisms  (plotfile,  validator),  and  the  remainder 
are  misspelled.  When  a  spellchecker  is  used  as  a  receiving  inspection  QA 
tool,  it  is  extremely  helpful  if  the  source  system  has  supplied  a  spelling 
exception  list.  In  that  case  the  17  words  in  the  first  group  would  not 
distract  the  person  performing  the  receiving  inspection  from  the  8  unac¬ 
ceptable  words. 

There  are  three  problems  bundled  together  in  this  one  list:  false 
errors  due  to  unrecognized  acronyms  and  other  special  words,  false  errors 
due  to  rejecting  legitimate  words,  and  true  errors  in  spelling.  The  latter 
again  points  up  the  need  to  supply  AQC  tools  (or  validate  the  sending 
system  tools). 

The  foregoing  discussion  would  seem  to  lend  some  support  for 
restoring  the  Special  Words  file  (exception  list  addendum  for  spellcheck 
software)  to  MIL-STD-1840A. 

Arn-Ref-1986-1  Statistics 


Table  2  below  shows  the  file  size  in  bytes  and  the  number  of 
tags  in  the  two  text  files.  The  statistics  do  not  include  the  “[co” 
comment  lines  used  to  record  fixes  to  the  text  files. 


File  Name 

Bytes 

Tags 

Table  2. 

TOOISOOOI. 

2,951 

200 

Text  File  Sizes  -  DOCOOl 

T001S0002. 

42,309 

426 

Totals 

45,260 

626 
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IGES  FUes 


Arn-Ref-1986-1  Analysis 

The  most  significant  finding  is  that  the  images  transferred  with  near 
perfect  accuracy.  The  less  than  perfect  aspect  had  to  do  primarily  with 
font  definitions.  Refer  to  Exhibits  3  and  4,  and  1 1  and  12. 

IGES-1  -  IGES  (Version  3.0)  does  not  have  the  capability  to  identify 
fonts  that  will  match  the  area  defined  for  the  note  (entity  212).  This 
deficiency  presents  a  serious  problem  for  those  contemplating  the  use  of 
MIL-STD-1840.  Text  in  illustrations  must  be  manipulated  at  the  destina¬ 
tion  system  to  fit  the  apparent  intended  note  area,  but  the  amount  of 
manual  intervention  required  to  achieve  this  “cut  and  try”  solution  makes 
a  mockery  of  the  “A”  in  Am.  A  proposed  solution  has  been  described  in 
Am  Report  87-002. 

Vendor-Related  Problems 

It  is  clear  from  examination  of  the  log  file  output  from  the  IGES  Data 
Analysis  (IDA)  ParserA^erify  software  that  there  are  several  points  on 
which  IDA  and  Auto-trol  disagree  in  regard  to  interpretation  of  the  IGES 
requirements.  Both  parties  have  been  supplied  with  copies  of  the  log  files 
along  with  a  request  to  “do  something.”  No  further  action  from  this  end  is 
planned  at  this  time.  If  there  are  true  deficiencies  in  the  Auto-trol  IGES 
preprocessor  output,  they  will  not  be  found  by  submitting  the  file  to  an 
Auto-trol  IGES  postprocessor. 

AITI-Ref-1986.1  Statistics 

The  statistics  tabulated  below  were  compiled  from  the  output  generated 
by  the  IGES  Data  Analysis  Parser/Verify  software.  The  complete  listings 
follow  the  text  of  this  section. 

Table  3  presents  data  on  the  number  of  records  in  the  file 
for  each  illustration.  The  seven  illustrations  in  this  document 
required  8,212  records  and  about  650,000  bytes  for  transmission  in 
IGES  uncompressed  ASCII  format. 


Test  Results 


Doc 

File 

P 

T 

Total 

Avg. 

Byte 

Table  3. 

Count  of  Records  per 

oeciioii  in  iiaia  rii6 

1 

1 

1 

3  858 

460 

1 

1323 

246 

1 

2 

1 

3 

382 

202 

1 

589 

246 

1 

3 

1 

3 

1312 

1034 

1 

2351 

286 

1 

4 

1 

3 

776 

462 

1 

1243 

256 

1 

5 

1 

3 

656 

374 

1 

1035 

252 

1 

6 

1 

3 

450 

257 

1 

712 

253 

1 

7 

1 

3 

610 

344 

1 

959 

251 

TOTAL 

7 

21 

5044 

3133 

7 

8212 

256 

8,2 1 2  records  of  80  bytes  =  664,7 60 


Table  4  presents  data  on  the  count  of  entity  types  and  forms  of  entities 
within  type,  shown  by  the  level  to  which  the  entity  and  form  combination 
was  assigned. 


File  Number  Table  4. 

Ent  Form  Lvl  0001  0002  0003  0004  0005  0006  0007  Total  Entity  Occurrence  Counts 


100 

1 

0 

0 

0 

2 

0 

0 

0 

2 

100 

2 

0 

0 

20 

38 

8 

11 

16 

93 

104 

0 

2 

0 

0 

0 

0 

0 

0 

1 

1 

106 

11 

2 

11 

0 

3 

0 

7 

4 

1 

26 

106 

11 

5 

0 

0 

0 

13 

0 

0 

0 

13 

106 

11 

15 

0 

0 

163 

0 

0 

0 

0 

163 

106 

12 

15 

0 

0 

5 

0 

0 

0 

0 

5 

110 

1 

0 

175 

191 

32 

13 

26 

73 

510 

no 

2 

262 

5 

51 

48 

47 

38 

61 

512 

110 

3 

0 

0 

0 

177 

0 

0 

0 

177 

no 

4 

0 

0 

0 

44 

96 

0 

0 

140 

no 

5 

0 

0 

10 

0 

0 

112 

120 

242 

no 

8 

136 

0 

0 

0 

0 

0 

0 

136 

no 

15 

0 

0 

164 

0 

125 

0 

0 

289 

124 

0 

2 

0 

0 

0 

0 

0 

0 

1 

1 

124 

0 

4 

0 

0 

0 

4 

0 

0 

0 

4 

212 

1 

4 

20 

11 

48 

30 

31 

33 

31 

204 

212 

1 

100 

0 

0 

1 

0 

1 

1 

1 

4 

Total 

429 

191 

656 

388 

328 

225 

305 

2522 
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Table  5. 

Entity  Count  by  Level 


Table  5  shows  the  entity  count  by  level  for  each  of  the  illustrations. 

It  would  be  beneficial  to  users  of  MIL-STD-1840  to  encourage  IGES 
pre-  and  postprocessor  vendors  to  implement  an  ASCII  compression 
algorithm. 


File  Number 


LvI 

0001  1 

0002 

0003 

0004 

0005 

0006 

0007 

Total 

1 

0 

175 

191 

34 

13 

26 

73 

512 

2 

273 

5 

74 

86 

62 

53 

80 

633 

3 

0 

0 

0 

177 

0 

0 

0 

177 

4 

20 

11 

48 

78 

127 

33 

31 

348 

5 

0 

0 

10 

13 

0 

112 

120 

255 

8 

136 

0 

0 

0 

0 

0 

0 

136 

15 

0 

0 

332 

0 

125 

0 

0 

457 

100 

0 

0 

1 

0 

1 

1 

1 

4 

TOTAL 

429 

191 

656 

388 

328 

225 

305 

2522 

It  is  recommended  that  sending  systems  be  provided  with  AQC  tools. 
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4  Summary  of  Recommendations 


AQC  Tools  for  Text  Files 

It  is  recommended  that  sending  systems  be  provided  with  AQC  tools 
and  improved  reference  documentation  to  assist  in  preparing  text  in 
accordance  with  MIL-M-28001.  The  primary  AQC  tool  would  be  a  tag 
analyzer  (lexical  scanner  and  syntax  parser). 

IGES  Improvements 

It  is  recommended  that  the  capability  of  IGES  be  expanded  to  include 
the  parameterized  definition  of  several  fonts.  Parameterized  fonts  would 
permit  the  exchange  of  illustrations  with  text  callouts  without  requiring 
manual  intervention  at  the  receiving  system  to  make  the  ASCII  strings  fit 
in  the  intended  callout  area  on  the  illustration.  A  proposed  solution  has 
been  presented  in  Am  Report  87-(X)2. 
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SECTION  II 

VALIDATION  PRE-TEST  ACTIVITY. 


2-1.  STATEMENT  OF  PRETEST  ACTIVITY. 

a.  SGML-AF  GenCode  Tag  Development 
S G M L-AF  (Air  Force  implementation  of  SGML)  has 
been  in  use  and  continued  development  for  some 
time.  Coding  tags  for  many  but  not  all  types  of 


documents  have  been  developed.  At  this  writing. 
Hill  AFB  and  Warner  Robins  AFB  are  using  the 
gencode  tags  developed  to  date  for  normal  produc¬ 
tion.  Figxire  2-1  shows  the  development  and  imple¬ 
mentation  status  for  several  document  tjrpes. 


Description 

Status 

Description 

Status 

MIL-M-38784A 

In  use 

Work  cords 

In  development 

Operation^  Supplements 

In  use 

MIL-M-38784B 

Not  contracted 

Safety  Supplements 

In  use 

Checklists 

In  development 

Time  Compliance  TOs 

In  use 

Flight  Manuals 

Not  contracted 

TCTO  Supplements 

In  use 

Job  Guides 

Not  contracted 

GENSTAT6.DG 


b.  IGES.  IGES  Version  3  was  released  in 
April,  1986.  By  design  most  IGES  entities  from  ear¬ 
lier  versions  will  be  upward  compatible  with  version 
3.  Part  of  the  validation  effort  will  be  to  determine 
if  the  IGES  entities  selected  for  Appendix  A  of  the 
Standard  vary  from  version  3  when  generated  by 
currently  existing  CAD  vendor  IGES  processors. 

IGES  has  had  little  more  than  token  use  as  a 
formal  delivery  vehicle  in  industry,  but  that  will 
change  rapidly  as  the  Standard  is  validated  and  con¬ 
tractual  agreements  begin  to  include  the  Standard. 

c.  CCITT  group  4.  CCITT  group  4  has  gained 
wide  acceptance  as  a  raster  data  exchange  and  stor¬ 
age  format  among  industry  leaders  in  electronic 
document  capture  and  storage.  The  validation  tests 
will  make  use  of  the  A  N  A  tech  V  A  N  A  raster  to  vec¬ 
tor  converter  in  the  ATOS  laboratory.  ANAtech  will 


be  releasing  (in  time  for  the  first  test)  an  updated 
software  package  that  converts  data  from  a  scanner 
to  CCITT  group  4  format  Additionally,  that  same 
software  can  receive  CCITT  group  4  and  output  the 
data  in  IGES  format  or  in  Auto-trol  format  This 
will  allow  a  'sanity  check'  when  dealing  with  CCITT 
group  4  data.  This  same  software  can  also  output 
the  data  in  the  tripled  v-bit  format  so  that  it  can 
accompany  text  when  output  to  the  triple-4  photo¬ 
typesetter  at  any  of  the  ATOS  sites. 

2-0.  PRETEST  ACTIVITY  The  test  tools  have 
been  validated  with  the  exception  of  the  SGML 
Parser.  This  tool  has  been  installed  and  is  under  test 
now. 
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b.  IGES.  IGES  Version  3  was  released  in 
April,  1986,  By  design  most  IGES  entities  from  ear¬ 
lier  versions  wiil  be  upward  compatible  with  version 
3.  F^art  of  the  validation  effort  will  be  to  determine 
if  the  IGES  entities  selected  for  Appendix  A  of  the 
■Standard  vary  from  version  3  when  generated  by 
currently  existing  (’AD  vendor  IGES  processors. 

IGES  has  had  little  more  than  token  use  as  a  for¬ 
mal  delivery  vehicle  in  industry,  but  that  will 
change  rapidly  as  the  Standard  is  validated  and 
contractual  agreements  begin  to  include  the 
Standard. 

c.  C C ITT  group  4.  CCITT  group  4  has  gained 
wide  acceptance  as  a  raster  data  exchange  and  stoi^ 
age  format  among  industry  leaders  in  electronic 
document  capture  and  storage.  The  validation  tests 


will  make  use  of  the  A  N  A  tech  V  A  N  A  raster  to  vec¬ 
tor  converter  in  the  ATOS  laboratory.  ANAtech  will 
be  releasing  lin  time  for  the  first  test)  an  updated 
software  package  that  converts  data  from  a  scan¬ 
ner  to  CCITT  group  4  format.  Additionally,  that 
same  software  can  receive  CCITT  group  4  and  out¬ 
put  the  data  in  IGES  format  or  in  Auto-Lrol  format. 
This  will  allow  d  sanity  check’  when  dealing  with 
CCITT  group  4  lata.  This  same  software  can  also 
output  the  data  in  the  tripl^I  v-bit  format  so  that  it 
can  accompany  text  when  output  to  the  Lriple-l  pho¬ 
totypesetter  at  any  of  Llie  ATOS  sites. 

d,  PRETEST  ACTIVITY.  The  test  tools  have 
been  validated  with  the  exception  of  the  SGML 
Parser.  This  tool  has  been  installed  and  is  under 
test  now. 


0—0 
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Figure  J-4  provides  a  software  development 
schedule. 


c.  Personnel.  The  testing  crew  will  be  staffed 
from  personnel  of  the  Advanced  Technology  Depart¬ 
ment  of  the  San  Diego  Division  of  SYSCO  N. 

d.  Orientation  Plan.  No  training  will  be 
required  for  tests  at  SYSCON. 

e.  Test  Materials  and  Equipment. 

(1)  Deliverable  Materials. 

•  Program  listing  and  operator  instructions  on 
magnetic  tape  for  DOC  DEC  verification 
software. 

•  Program  listings  and  operator  instructions  on 
magnetic  tape  for  miscellaneous  control  and 
utility  software. 


•  Program  listing  and  operator  instructions  on 
magnetic  tape  for  for  software  to  load  AITI 
document  into  ATOS. 

•  Program  listing  and  operator  instructions  on 
magnetic  tape  for  for  extracting  a  document 
from  ATOS  and  building  an  AITI  Standard 
magnetic  tape. 

•  Benchmark  database  files  on  magnetic  tape  and 
listings 

•  Revised  style  and  format  files 

(2)  Site  Supplied  Materials.  SYSCON  will 
provide  computer  supplies,  such  as  paper  and  mag¬ 
netic  tapes,  and  computer  time  and  mass  storage  for 
data. 


3^  Chang#  1 
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Figure  M  Software  Development  Scnedule 


c\  Personnel.  The  testing  crew  will  be  staffed 
from  personnel  of  the  Advanced  Technology  Depart- 
ment  of  the  San  Diego  Division  of  SYSCON. 

d.  Orientation  Plan.  No  training  will  be 
required  for  tests  at  SYSCON. 

e.  Test  Materials  and  Equipment. 

Ill  Deliverable  Materials. 

•  Program  listing  and  operator  instructions  on 
magnetic  tape  for  DOC  DEC  verification 
software. 

•  Program  listings  and  operator  instructions  on 
magnetic  tape  for  miscellaneous  control  utility 
software. 


•  Program  listing  and  operator  instructions  on 
magnetic  tape  for  software  to  load  AITI  docu¬ 
ment  into  AT  OS. 

•  Program  listing  and  operator  instructions  on 
magnetic  tape  for  extracting  a  document  from 
ATOS  and  building  an  AITI  Standard  magnetic 
tape. 

•  Benchmark  database  files  on  magnetic  tape  and 
listings. 

•  Revised  style  and  format  files. 

(2)  Site  Supplied  Materials.NS YSCON  will 
provide  computer  supplies,  such  as  paper  and  mag¬ 
netic  tapes,  and  computer  time  and  mass  storage  for 
data. 
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SECTION  IV 

TEST  SPECIFICATION  AND  EVALUATION 


4-1.  TEST  SPECIFICATION.  This  section 
presents  four  major  topics:  the  lest  requirements, 
the  test  methodology,  the  progression  of  tests,  and 
the  evaluation  of  test  results. 

a.  Requirements.  The  test  requirements  are 
allocated  to  four  categories:  magnetic  tape  media, 
the  Document  Declaration  File,  the  Text  files,  the 
IGES  files,  and  the  CCITT  group  4  files. 

(I)  Magnetic  Tape  Media  Requirements.  To 
be  accepted,  the  magnetic  tape  must  meet  the  fol¬ 
lowing  requirements. 

1.  The  magnetic  tape  must  be  formatted  in  accor¬ 
dance  with  FIPS  PUB  79  (reference  1). 

2.  The  tape  volume  and  file  labels  shall  conform 
with  level  three  or  level  four  of  FIPS  PUB  79. 

3.  The  data  must  be  written  on  9^ack  tape  at  a 
density  of  1600  or  6250  bpi  in  accordance  with  FIPS 
PUBS  25,  50,  79  (references  2,  3,  1). 

4.  The  tape  volume  identifier  must  consist  of  six 
characters.  The  first  four  characters  shall  identify 
the  set  and  the  last  two  character  shall  consist  of 
the  digits  0-9  and  represent  the  number  of  the  tape 
volume  in  the  set 

5.  The  characters  in  the  label  must  be  limited  to 
the  ASCII  uppercase  letters  and  the  digits  0-9. 

6.  The  Document  Declaration  and  Text  files  must 
be  recorded  with  ANSI  (reference  7)  type  D  variable 
length  records  with  block  lengths  of  2048  bytes. 

7.  The  IGES  (reference  8)  files  must  be  recorded 
with  ANSI  t3rpe  F  fixed  length  80  byte  records  with 
block  lengths  of  2000  bytes. 

8.  The  CCITT  group  4  (reference  6)  files  must  be 
recorded  with  the  first  block  containing  the  the 

I  required  header  records  in  ANSI  type  F  fixed  length 
records  with  padding  to  2048  bytes.  The  CCITT  data 
must  be  written  with  128  byte  ANSI  type  F  records 
in  blocks  of  2048  bytes. 

9.  The  Docximent  Declaration  file(s)  must  precede 
all  other  types  of  files  on  the  tape  volume(s)- 

10.  The  data  files  must  be  grouped  in  the  same 
order  as  the  Document  Declaration  files.  Files  from 
different  documents  shall  not  be  intermixed. 

11.  All  records  in  the  Document  Declaration  File 
and  all  header  records  specified  for  the  text  and 
illustration  files  are  required. 


(2)  Document  Declaration  File  Require¬ 
ments.  To  be  accepted,  a  Document  Declaration  file 
must  meet  the  following  requirements. 

1.  The  filename  and  all  records  in  the  file  must  be 
ASCII  characters. 

2.  The  filename  must  contain  exactly  six 
characters. 

3.  The  filename  must  be  unique  with  respect  to 
any  other  file  name  to  be  found  in  the  set  of  files 
being  transferred. 

4.  The  first  three  characters  of  the  filename  must 
be  ‘DOC*. 

5.  The  record  type  must  be  ANSI  type  D. 

6.  The  record  lengths  must  range  from  one  byte  to 
256  bytes. 

7.  RECORD  1 -must  contain  an  ASCII  string 
agreed  upon  by  the  data  source  and  the  destination 
(SYSCON). 

8.  RECORD  2  - must  contain  an  agreed  upon 
ASCII  string. 

9.  RECORD  3  -  must  contain  an  agreed  upon 
ASCII  string,  or ‘NONE*. 

10.  RECORD  4 -must  contain  an  agreed  upon 
ASCII  string,  or  ‘ORIGINAL*. 

11.  RECORD  5 -must  contain  an  eight  character 
string  representing  the  date  in  the  format 

YYYY MM DD.  where  1970  ^  YYYY  $  1987;  01  ^  I 
MM  ^  12:01  ^  DD  ^  31. 

12.  RECORD  6 -must  contain  an  agreed  upon 
ASCII  string. 

13.  RECORD  7 -must  contain  an  agreed  upon 
ASCII  string. 

14.  RECORD  8 -must  contain  an  agreed  upon 
ASCII  string,  or  ‘NONE*. 

15.  RECORD  9 -must  contain  an  eight  character 
string  representing  the  date  in  the  format 

YYYY MMDD,  where  1986  $  YYYY  g  1987;  01  ^ 

MM  ^  12;  01  ^  DD  ^  31. 

16.  RECORD  10 -must  contain  an  agreed  upon 
ASCII  string,  or ‘NONE*. 

17.  RECORD  1 1  -  must  contain  one,  two,  three  or  I 
four  groups  of  ASCII  digits.  The  groups  must  be  I 
separated  with  a  comma.  A  space  code  following  the 
comma  is  acceptable.  The  first  group  must 


24 


AITI  REPORT  87-005 
Exhibit  8  -  As  transmitted 
and  processed 


T.O.  AITHJEM61 


SECTION  IV 

TEST  SPECIFICATION  AND  EVALUATION 


4-1.  TEST  SPECIFIC  ATIO  N.  This  section 
presents  four  major  topics:  the  test  requirements, 
the  test  methodology,  the  progression  of  tests,  and 
the  evaluation  of  test  results. 

a.  Requirements.  The  test  requirements  are 
allocated  to  four  categories:  magnetic  tape  media, 
the  Document  Declaration  File,  the  Text  files,  the 
IGES  files,  and  the  CCITT  group  4  files. 

(i)  Magnetic  Tape  Media  RequirementsATo 
be  accepted,  the  magnetic  tape  must  meet  the  fol¬ 
lowing  requirements. 

1.  The  magnetic  tape  must  be  formatted  in  accor¬ 
dance  with  FIPS  PUB  79  (reference  1). 

2.  The  tape  volume  and  file  labels  shall  conform 
with  level  three  or  level  four  of  FIPS  PUB  79. 

3.  The  data  must  be  written  on  9-track  tape  at  a 
density  of  1600  or  6250  bpi  in  accordance  with  FIPS 
PUBS  25,  50,  79  (references  2,  3,  1). 

4.  The  tape  volume  identifier  must  consist  of  six 
characters.  The  first  four  characters  shall  identify 
the  set  and  the  last  two  characters  shall  consist  of 
the  digits  0-9  and  represent  the  number  of  the  tape 
volume  in  the  set 

5.  The  characters  in  the  label  must  be  limited  to 
the  ASCII  uppercase  letters  and  the  digits  0-9. 

6.  The  Document  Declaration  and  Text  files  must 
be  recc’  led  with  ANSI  (reference  7}  type  D  variable 
length  records  with  block  lengths  of  2048  bytes. 

7.  The  IGES  (reference  8)  fOes  must  be  recorded 
with  ANSI  type  F  fixed  length  80  byte  records  with 
block  lengths  of  2000  bytes. 

8.  The  CCITT  group  4  (reference  6)  files  must  be 
recorded  with  the  first  block  containing  the  required 
header  records  in  ANSI  type  F  fixed  length  records 
with  padding  to  2048  bytes.  The  CCITT  data  must 
be  written  with  128  byte  ANSI  type  F  records  in 
blocks  of  2048  bytes. 

9.  The  Document  Declaration  file(s)  must  precede 
all  other  types  of  files  on  the  tape  volume(s). 

10.  The  data  files  must  be  grouped  in  the  same 
order  as  the  Document  Declaration  files.  Files  from 
different  documents  shall  not  be  intermixed. 

11.  All  records  in  the  Document  Declaration  File 
and  all  header  records  specified  for  the  text  and 
illustration  files  are  required. 


(2)  Document  Declaration  File  Require¬ 
ments.,  To  be  accepted,  a  Document  Declaration  file 
must  meet  the  following  requirements. 

1.  The  filename  and  all  records  in  the  file  must  be 
ASCII  characters. 

2.  The  filename  must  contain  exactly  six 
characters. 

3.  The  filename  must  be  unique  with  respect  to 
any  other  file  name  to  be  found  in  the  set  of  files 
being  transferred. 

4.  The  first  three  characters  of  the  filename  must 
be  D0C\ 

5.  The  record  type  must  be  ANSI  type  D. 

6.  The  record  lengths  must  range  from  one  byte  to 
256  bytes. 

7.  RECORD  1 -must  contain  an  ASCII  string 
agreed  upon  by  the  data  source  and  the  destination 
(SYSCON). 

8.  RECORD  2 -must  contain  an  agreed  upon 
ASCII  string. 

9.  RECORD  3 -must  contain  an  agreed  upon 
ASCII  string,  or  NONE’. 

10.  RECORD  4 -must  contain  an  agreed  upon 
ASCII  string,  or  ORIGINAL’. 

11.  RECORDS  -must  contain  an  eight  character 
string  representing  the  date  in  the  format 
YYYYMMDD,  where  197(3  ??  YYYY  ??  1987;  01  ?? 
MM  ??  12:  01  ??  DD  ??  31. 

12.  RECORD  6 -must  contain  an  agreed  upon 
ASCII  string. 

13.  RECORD  7  - must  contain  an  agreed  upon 
ASCII  string. 

14.  RECORD  8 -must  contain  an  agreed  upon 
ASCII  string,  or  NONE’. 

15.  RECORD  9 -must  contain  an  eight  character 
string  representing  the  date  in  the  format 
YYYYMMDD,  where  1986  ??  YYYY  ??  1987;  01  ?? 
MM  ??  12:  ol  ??  DD  ??  31. 

16.  RECORD  10 -must  contain  an  agreed  upon 
ASCII  string,  or  NONE’. 

17.  RECORD  11 -must  contain  one,  two,  three  or 
four  groups  of  ASCII  digits.  The  groups  must  be 
separated  with  a  comma.  A  space  code  foUowing  the 
comma  is  acceptable.  The  first  group  must 
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5-1.  TEST  DESCRIPTION. 

Test  Control.  Tests  are  controlled  by  a 
script  like  procedure  which  is  executed  from  the 
computer  operators  console.  DEC  Command  Lan¬ 
guage  command  files  are  incorporated  into  the 
script  by  execution.  A  manual  test  log  will  also  be 
maintained  to  record  any  observations  or  unex*- 
pected  events. 

Additional  test  control  will  be  provided  by  occa¬ 
sional  replication  of  the  test  to  demonstrate 
reproducibility. 

Figures  5-1  through  illustrate  the  flow  of  the 
test  data  through  the  various  steps  of  the  test  All 
tests  will  follow  the  same  path.  The  only  variations 
in  the  test  will  be  in  the  data  content 

The  first  step  in  each  test  will  be  to  validate  the 
Document  Declaration  File(s).  (See  Fig\ire  5-1),  If 
there  is  some  difficulty  detected  then  trouble  shoot¬ 
ing  procedures  will  be  applied.  If  the  error  is  genu¬ 
ine  (and  therefore  unrepairable)  the  test  will  be  ter¬ 
minated.  If  the  difficulty  is  due  to  operator  error  or 
other  external  cause,  the  test  will  be  restarted. 

When  the  Document  Declaration  files  are  acceptr 
able,  then  the  text,  IGES  and  CCITT  files  will  be 
validated.  This  is  accomplished  by  counting  the  files 
and  by  examining  the  header  records  at  the  begin¬ 
ning  of  each  of  the  files.  If  difficulties  are  encoun¬ 
tered  the  same  trouble  shooting  procedures  as 
described  for  the  Document  Declaration  File  will  be 
followed. 

During  the  period  of  time  described  above,  all  of 
the  software  processes  employed  will  generate  pro¬ 
cess  status  messages  and  error  detection  messages. 
These  messages  will  be  stored  on  magnetic  disk  and 
included  in  the  test  report 

The  test  now  enters  a  new  phase  where  the  individ¬ 
ual  data  types  of  the  document  are  examined.  Each 
type  of  data  (text  tagged  with  SGML-AF.  and  illus¬ 
trations  in  IGES  or  CCITT  group  4  format)  requires 
separate  treatment  The  procesing  for  text  is  shown 
in  the  lower  part  of  Figure  5-1.  In  the  future,  the 
Datalogics  gencode  parser  may  be  added  to  or  sub¬ 
stituted  for  the  Datalogics  Pager  software  that  com¬ 
poses  the  text  for  display.  This  part  of  the  diagram 
shows  a  consistent  feature  of  all  the  tests:  the  com¬ 
parison  of  some  part  of  the  data  with  the  printed 
copy. 


Figure  5-2  shows  the  processing  of  IGES  data.  The 
first  step  submits  the  IGES  data  to  a  Parser/ Veri¬ 
fier  from  IGES  Data  Analysis.  The  software  detects 
errors  in  the  data  and  verifies  the  IGES  version 
number  with  which  the  data  is  in  compliance. 
Although  not  shown  on  the  illustration,  if  there  are 
any  errors  detected,  they  will  be  recorded  and 
trouble  shooting  procedures  applied  as  previously 
described.  When  the  data  successfully  passes  this 
examination,  it  will  be  converted  from  IGES  format 
to  Auto-trol  format  (S-5000).  The  data  in  S-5000  for¬ 
mat  will  then  be  converted  to  triple-I  UPF  format 
(the  same  used  by  ATOS).  This  data  will  then  be 
converted  with  SYSCO N  software  for  output  on  the 
Datalogics/QMS  1200  Laser  printer.  Again,  the  out¬ 
put  will  be  compared  with  the  paper  document  If 
there  are- discrepancies,  the  trouble  shooting  proce¬ 
dures  will  be  applied. 

Figure  5-3  shows  the  processing  of  CCITT  group  4 
data.  The  first  step  is  the  conversion  of  the  com¬ 
pressed  raster  format  to  a  vector  format  that  is 
native  to  the  AN  A  tech  workstation.  Both  visual 
examination  and  error  detection  by  software  are 
possible  in  this  process.  The  vector  formatted  data 
is  then  passed  to  an  AN  Atech  process  which  con¬ 
verts  the  data  to  a  Standard  Output  Format.  The 
SOF  data  is  then  processed  by  an  Auto-trol  program 
that  converts  it  to  Auto-trol  ^000  format.  The 
illustration  in  its  S-5000  form  can  then  be  viewed  at 
the  Auto^ol  AGW  workstation  and  compared  with 
the  paper  document  If  required,  the  illustration  can 
be  output  on  the  Laser  printer  in  the  same  way  that 
the  IGES  data  is  output  (not  shown  on  the  figure). 

If  no  trouble  shooting  is  required,  then  the  original 
CCITT  data  will  be  converted  using  AN  Atech 
software  to  the  triple-I  v-bit  format  for  output  on  a 
triple-!  typesetter. 

Figure  5H  shows  the  final  process  where  the  whole 
document  is  assembled  and  typeset  The  typesetter 
output  (resin  coated  paper)  is  then  compared  with 
the  printed  version  of  the  document  If  the  compari¬ 
son  is  favorable  (see  section  4.4)  then  the  data  will 
be  transferred  from  temporary  storage  to  the 
benchmark  data  base. 
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5-1.  TEST  DESCRIPTION. 

Test  Control.  Test  are  controlled  by  a  script 
like  procedure  which  is  executed  from  the  computer 
operators  console.  DEC  Command  Language  com¬ 
mand  files  are  incorporated  into  the  script  bv  execu¬ 
tion.  A  manual  test  log  will  also  be  maintained  to 
records  any  observations  or  unexpected  events. 

Additional  test  control  will  be  provided  by  occas¬ 
sional  replication  of  the  test  to  demonstrate 
reproducibility. 

Figures  5-1  through  5-i  Qlustrate  the  flow  of  the 
test  data  through  the  various  steps  of  the  test  All 
tests  will  follow  the  same  path.  The  only  variations 
in  the  test  wdl  be  in  the  data  content 

The  first  step  in  each  test  will  be  to  validate  the 
Document  Declaration  File(s),  (See  Figure  5-1).  If 
there  is  some  difficulty  detected  then  troubleshoot- 
ing  procedures  will  be  applied.  If  the  error  is  genu¬ 
ine  (and  therefore  unrepairable)  the  test  will  be  ter¬ 
minated.  If  the  difficulty  is  due  to  operator  error  or 
other  external  cause,  the  test  will  be  restarted. 

When  the  Document  Declaration  Files  are  accept¬ 
able,  then  the  text  IGES  and  CCITT  files  will  be 
validated.  This  is  accomplished  by  counting  the  files 
and  by  examming  the  header  records  at  the  begin¬ 
ning  of  each  of  the  files.  If  difficulties  are  encoun¬ 
tered  the  same  troubieshootmg  procedures  as 
described  for  the  Document  Declaration  File  will  be 
followed. 

During  the  period  of  time  described  above,  aD  of  the 
software  processes  employed  will  generate  process 
status  messages  and  error  detection  messages. 

These  messages  will  be  stored  on  magnetic  disk  and 
included  in  the  test  report. 

The  test  now  enters  a  new  phase  where  the  individ¬ 
ual  data  types  of  the  document  are  examined.  Each 
type  of  data  (text  tagged  with  SG.ML-AF,  and  illus¬ 
trations  in  IGES  or  CCITT  group  4  format)  requires 
separate  treatment  The  processing  for  text  is 
shown  in  the  lower  part  of  Figure  5-1.  In  the  future, 
the  Datalogics  gencode  parser  may  be  added  to  or 
substituted  for  the  Datalogics  Pager  software  that 
composes  the  text  for  display.  This  part  of  the  dia¬ 
gram  shows  a  consistent  feature  of  all  the  tests:  the 


comparison  of  some  part  of  the  data  with  the 
printed  copy. 

Figure  5^  shows  the  processing  of  IGES  data.  The 
first  step  submits  the  IGES  data  to  a  Parser/Veri¬ 
fier  from  IGES  Data  Analysis.  The  software  detects 
errors  in  the  data  and  verifies  the  IGES  version 
number  with  which  the  data  is  in  compliance. 
Although  not  shown  on  the  illustration,  if  there  are 
any  errors  detected,  they  will  be  recorded  and  trou¬ 
bleshooting  procedures  applied  as  previously 
described.  When  the  data  successfully  passes  this 
examination,  it  will  be  converted  from  IGES  format 
to  Auto-Trol  format  (S-oOOO).  The  data  in  S-5000  for¬ 
mat  will  then  be  converted  to  triple-I  UPF  format 
(the  same  used  by  AT  OS).  This  data  will  then  be 
converted  with  SYSCO  N  software  for  output  on  the 
Datalogics/Q MS  1200  Laser  printer.  Again,  the  out¬ 
put  will  be  compared  with  the  paper  document.  If 
there  are  discrepancies,  the  troubleshooting  proce¬ 
dure  will. be  applied.  Figure  5-3  shows  the  process¬ 
ing  of  CCITT  group  4  data.  The  first  step  is  the 
conversion  of  the  compressed  raster  format  to  a  vec¬ 
tor  format  that  is  native  to  the  A  N  A  tech  worksta¬ 
tion.  Both  visual  examination  and  error  detection  by 
software  are  possible  in  this  process.  The  vector 
formatted  data  is  then  passed  to  an  AN  A  tech  pro¬ 
cess  which  converts  the  data  to  a  Standard  Output 
Format.  The  SOF  data  is  then  processed  by  an 
Auto-trol  program  that  converts  it  to  Auto-trol  S- 
5000  format.  The  illustration  in  its  S-5000  form  can 
then  be  viewed  at  the  Auto-trol  AG  W  workstation 
and  compared  with  the  paper  document.  If  required, 
the  illustration  can  be  output  on  the  Laser  printer  in 
the  same  way  that  the  IGES  data  is  output  (not 
shown  on  the  figure).  If  no  trouble-shooting  is 
required,  then  the  original  CCITT  data  will  be  con¬ 
verted  using  A  N  A  tech  software  to  the  triple-I  v-bit 
format  for  output  on  a  triple-I  typesetter.  Figure  5^ 
shows  the  final  process  where  the  whole  document 
is  assembled  and  typeset.  The  typesetter  output 
(resin  coated  paper)  is  then  compeired  with  the 
printed  version  of  the  document  If  the  comparison 
is  favorable  (see  section  4.4)  then  the  data  will  be 
transferred  from  temporary  storage  to  the  bench¬ 
mark  data  base. 
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